When a hard disk drive (HDD) has more than one command to execute, the commands are placed in a queue from which the next command is chosen. A Rotational Position Optimization (RPO) algorithm is used to reorder the commands for execution. Presently, hard disk drives use a Shortest Access Time First (SATF) RPO algorithm to determine which command to select. This algorithm works as follows: given a set of commands in a queue, choose the command that can be started (accessed) first. This calculation has two parts, namely, the time to perform the seek and settle operation from the current cylinder to the target cylinder, and the latency (also referred to as “extra time” herein) between this point and the starting sector for the command. Together these parts make up the estimated access time (EAT) for each queued command. The SATF algorithm depends on accurate estimates of the access time. If the estimate is too low, the actuator may settle on track after the desired sector has passed rotationally resulting in a ‘miss’ which adds one full revolution to the access time and, thus, degrading performance. On the other hand, if the estimate is too high, the optimal command candidate is not chosen for execution.
In any case, a SATF RPO algorithm simply selects the command which can be started first. A Delta Expected Access Time (DEAT) RPO algorithm has been proposed as an improved SATF by choosing the command that has the shortest access time as well as an acceptable probability of success. The DEAT algorithm is disclosed in U.S. Pat. No. 6,725,327 incorporated herein by reference.
Apart from RPO considerations, some HDD applications such as, e.g., Redundant Arrays of Independent Disks (RAID) applications use commands each of which involves multiple disk operations. For instance, to generate parity data that can be used in error recovery, XOR commands are used which involve one or more reads, an XOR operation, and one or more writes of the result. In current hard disk drive firmware, XOR commands are typically treated as non-read/write commands and do not take advantage of RPO to reduce disk latencies. That is, the RPO algorithms do not optimize XOR commands in the same advantageous way they optimize data read and data write commands. It may now be understood that as used herein, a “data read” and a “data write” respectively refer to the non-XOR reads and writes conventionally scheduled by RPO algorithms, and not to reads and writes that are only made necessary pursuant to executing XOR commands.
Further, as recognized herein XOR commands typically are not sequentially attached to one another. That is, multiple XOR media-access commands are not coalesced to reduce the number of separate disk accesses if they represent LBA ranges that are sequential. As further understood herein, however, most XOR commands involve ‘read-modify-write’ type accesses to the command's LBA range which can be better optimized.
Currently, various types of XOR commands are used, all of which can be improved by present principles. As one example, a so-called “XPWrite” command can be used in which the data transferred from the host is XORed with the existing data on the media, and the resulting data is then written to the media. As another example, an “XDWriteRead” operation can be used wherein the data transferred from the host is XORed with data read from the media. The data transferred from the host is then written to the media, while the XORed data is returned to the host.
Regardless of the specific type of XOR command, the present invention is directed to reducing the overall rotational latencies involved in the read and write portions of the XOR command. The present invention critically recognizes that these latencies exist because the three steps of an XOR—read, buffer XOR, and write—are executed in sequence without regard for disk latency. Furthermore, the present invention recognizes that a large amount of latency may exist between the end of the write operation of one XOR command and the start of the read of the next XOR command.